IBIS Macromodel Task Group Meeting date: 11 August 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Todd Bermensolo * Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Ambrish to find out whether his team would have any interest in taking some of their BCI protocols public if there were a process to do so. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 04 meeting. Randy moved to approve the minutes. Lance seconded the motion. There were no objections. ------------- New Discussion: BIRD181.2: Bob reported that he and Mike L. have taken this topic up in the Quality task group. They will keep Radek (and anyone else interested) up to date and eventually bring it back to ATM for further discussion. Support PI modeling/simulation in IBIS: Zhiping noted that he was focusing his attention on the upcoming IBIS Summit in conjunction with the IEEE EMC SI+PI symposium. The IBIS Summit is on August 28th from 1 to 5 PM CST. Bob reported that Zhiping had submitted some ideas, and they now have 9 potential presentations. DDR5 DQ Write Protocol: Walter reviewed an updated version of his "DDR5_DQ_Write_Protocol (BIRD147/201)" presentation. He noted that he'd had to make more changes to the original than he had anticipated. Some changes were based on pushback he got from reviewers, and some were features he decided we need to support. slide 2: Pushback on Rx Calculating Metrics, Support for BIRD197 and BIRD204 - Walter said that he received several requests not to define the metrics that the Rx would calculate from its output IR or waveform. - Modified the protocol so that: - Rx AMI_Impulse returns its IR to the Tx AMI_Impulse - Rx AMI_GetWave returns the wave and clock_times to the Tx AMI_GetWave - Added support for BIRD197 (DC_Offset) and BIRD204(DQ-DQS GetWave flow). - Proposal now indicates which parameters are required and which are optional. slide 6: What the Tx tells the Rx each iteration Walter noted that he'd added DQS_Skew so the Tx could adjust the DQ-DQS skew in the Rx, assuming the Rx DQ model supports the DQ-DQS clock forwarding flow BIRD204. He also noted that he'd added a sequence number to aid in debugging with protocol issues, e.g., file system flushing issues in the case of BIRD147. - JEDEC protocol - Sequence # (New) - Gain register setting - VrefDQ register setting - DFE indices and register settings - DQS_Skew (New) - Generic protocol - same information, but passing real values instead of integral register settings. - VrefDQ setting and DQS_Skew are optional. The others are mandatory. slide 7: What the Rx tells the Tx each iteration (JEDEC protocol) Walter noted the following new additions for AMI_Impulse (statistical flow): - Sequence # - DC_Offset - DQS_in_clock_times (Boolean) - Impulse_Response He said DC_Offset is returned by the Rx AMI_Impulse the first time it is called. It simply takes the value the EDA tool set and passes it back to the Tx. The DQS_in_clock_times lets the Rx tell the Tx whether it is doing the DQ-DQS clock forwarded flow. - Impulse_Response and Sequence are required. The slide also defines a protocol for the GetWave flow (BIRD147). The wave and clock_times are returned by the Rx in the GetWave flow. - Wave and Sequence are required. slide 8: What the Rx tells the Tx each iteration (Generic protocol) - similar updates for the generic version Arpad asked why Walter was now defining the GetWave protocol, since this had been a statistical BCI protocol. Walter said it was a simple extension to define the protocol for time domain too, and it would be important for training DQS-DQ skew. slide 9: Tx is now responsible for determining "goodness" of the Rx's output - sample spacing of the IR and/or waveform is set by the EDA tool and passed in through the AMI_Init functions existing sample_interval argument - Tx can employ its own techniques to analyze the IR or wave from the Rx. slide 10: Notes on Sequence - Incrementing sequence counter allows for detecting and debugging various issues caused by the model, EDA tool, file system, etc. slide 11: AMI_GetWave File names written by Tx and Rx: - Tx - output filename shall be .Tx.txt - Rx - output filename shall be .Rx.txt slide 12: VrefDQ_Register and VrefDQ_Value Rules - Ignored by the Rx if DC_Offset is not specified in the Rx .ami file - If DC_Offset is specified in the Rx .ami file: - If Tx doesn't specify, the Rx should choose optimal setting/value and return them to the Tx. - If Tx does specify, the Rx should try to honor the request and return the actual values to the Tx. Walter said one of the ways the hardware trains itself is that the Tx will sweep the values of VrefDQ up and down and the Skew left and right until it sees errors. So the protocol supports doing that, and the Rx model has a way to tell the Tx if it has a DC_Offset parameter, otherwise setting VrefDQ is moot. - slide 13: Rx May Return Values when the Tx request a Register Setting and Return a Register Setting when the Tx Requests a Value - JEDEC protocol - Rx shall know how to map JEDEC register setting integer values to float values for each of the following VrefDQ, Gain, DFE Taps. - Rx may return values to the Tx. - Generic protocol - Rx may know how to map JEDEC register setting integer values to float values for each of the following VrefDQ, Gain, DFE Taps. - Rx may return the register settings and values to the Tx. - slide 14: BIRD204 support Walter said that BIRD204 was largely intended for DDR read cycles, where the controller has a phase interpolator. But for writes, the controller sets the DQS skew so it arrives at the memory 90 degrees out of phase with the DQ. The skew also affects when the DFE taps get latched. He recalled that for SerDes systems the CDR normally generates two clocks, one for when to sample the latch, and another one half a UI away that controls when the next set of DFE coefficients is latched into the adder. Walter said he'd added two new protocol parameters to support this: - DQS_in_clock_times - lets the Rx tell the Tx if it has the DQS waveform too. - DQS_Skew - lets the Tx adjust the DQS-DQ skew at the Rx. - slide 15: Standard Initialization of AMI_Impulse calls, Interaction with BIRD204 and BIRD197 - Describes the initialization sequence. - First call to Tx AMI_Impulse - shuts off its own equalization - tells the Rx to turn off its Gain and DFE. - Rx can then return DC_Offset and DQS_in_clock_times. - Tx AMI_Impulse can then search for optimal solution (statistical) - Tx AMI GetWave can continue the search in time domain simulation - If the BCI training is GetWave only, then the first call to Rx AMI_GetWave returns the DC_Offset and DQS_in_clock_times to the Tx. - slide 16: Next steps Walter said he planned to write up the actual protocols in a Word document, review it in ATM, and then publish it in the Open Forum. Arpad asked if both models had to support statistical and time-domain optimization, or if the protocols would handle the case in which one model was Init Only or one was GetWave Only. Walter said the protocols could work as long as both models supported the mode(s) being used. He said this was a good question, and that if we wanted to support GetWave only optimization then the protocol needed a mechanism for the Rx to return info to the Tx on the first GetWave call (see the last line of slide 15 (above), which Walter added during the meeting. This change appears in the version he emailed to ATM right after the meeting). Arpad asked about how to proceed. Walter said the presentation was sort of a functional spec. He planned to write a final protocol document. Randy said he thought the changes Walter presented all made sense. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Walter to send his updated presentation to ATM. ------------- Next meeting: 18 August 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives